FHIR © HL7.org  |  Server Home  |  FHIR Server FHIR Server 3.7.16  |  FHIR Version n/a  User: [n/a]

Resource Requirements/FHIR Server from package hl7.ehrs.uv.phrsfmr2#current (47 ms)

Package hl7.ehrs.uv.phrsfmr2
Type Requirements
Id Id
FHIR Version R5
Source http://hl7.org/ehrs/uv/phrsfmr2/https://build.fhir.org/ig/HL7/phrsfm-ig/Requirements-PHRSFMR2-PH.1.1.html
Url http://hl7.org/ehrs/uv/phrsfmr2/Requirements/PHRSFMR2-PH.1.1
Version 2.0.1-ballot
Status active
Date 2025-04-03T15:15:30+00:00
Name PH_1_1_Identify_and_Maintain_a_PHR_Account_Holder_Record
Title PH.1.1 Identify and Maintain a PHR Account Holder Record (Function)
Experimental False
Authority hl7
Description Unambiguously identify the PHR Account Holder; correctly link the information with the PHR Account Holder and vice-versa.
Purpose The PHR Account Holder must be confident that the system can reliably and uniquely identify them and provide access to their health record. Nothing precludes the PHR Account Holder from having more than one PHR such as a tethered PHR-S with their Primary Care Provider and a separate self-maintained PHR. The following functions apply to a single PHR system (PHR-S).

Resources that use this resource

No resources found


Resources that this resource uses

No resources found



Narrative

Note: links and images are rebased to the (stated) source

Statement N:

Unambiguously identify the PHR Account Holder; correctly link the information with the PHR Account Holder and vice-versa.

Description I:

The PHR Account Holder must be confident that the system can reliably and uniquely identify them and provide access to their health record. Nothing precludes the PHR Account Holder from having more than one PHR such as a tethered PHR-S with their Primary Care Provider and a separate self-maintained PHR. The following functions apply to a single PHR system (PHR-S).

Actors:
ehr
Criteria N:
PH.1.1#01 SHOULD

The system SHOULD present a user guide or training material to assist the PHR Account Holder in installing, initializing, registering, or operating their PHR.

PH.1.1#02 SHALL

The system SHALL provide the ability to store more than one unique identifier for each PHR Account Holder's record. For example, the PHR Account Holder may have received health information from multiple caregivers, each caregiver having a unique Patient Identifier for that PHR Account Holder (also known as an Account Number). When the PHR Account Holder shares information with an individual caregiver, the PHR Account Holder may desire to utilize the Patient Identifier that is known to that specific caregiver.

PH.1.1#03 SHOULD

The system SHOULD provide the ability to capture, store, and integrate and/or link the PHR Account Holder's unique identifiers from multiple external sources (e.g., medical record number, insurance account number, or voluntary unique identifiers).

PH.1.1#04 SHALL

The system SHALL provide the ability to uniquely identify a PHR Account Holder.

PH.1.1#05 SHOULD

The system SHOULD provide the ability (through a controlled method) to capture, integrate, and/or link information that is determined to be the PHR Account Holder's information that is stored in external systems. Note: A controlled method enables the PHR Account Holder to choose a course of action from a limited set of actions. For example, the PHR-S could provide a controlled method by which the PHR Account Holder could choose to link to an external DICOM image, but import the Report regarding that DICOM image instead.

PH.1.1#06 conditional SHALL

IF health information has been incorrectly associated with a PHR Account Holder, THEN the system SHALL provide the ability to annotate the information as being erroneous (or as believed to be erroneous) in the PHR Account Holder's account in which it was incorrectly associated, and represent that information as being erroneous.

PH.1.1#07 dependent conditional SHOULD

IF health information has been incorrectly associated with a PHR Account Holder, THEN the system SHOULD provide the ability to transmit information regarding the error to the source of the information according to organizational policy and/or jurisdictional law.

PH.1.1#08 dependent SHOULD

The system SHOULD provide the ability to archive, delete, and/or purge part or all of a PHR Account Holder's information (e.g., information that is obsolete, inactive, or nullified) according to user preference and/or consent, organizational policy (e.g., according to a statement of terms and conditions), and/or jurisdictional law.


Source

{
  "resourceType" : "Requirements",
  "id" : "PHRSFMR2-PH.1.1",
  "meta" : {
    "profile" : [
      "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/FMFunction"
    ]
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <span id=\"description\"><b>Statement <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b> <div><p>Unambiguously identify the PHR Account Holder; correctly link the information with the PHR Account Holder and vice-versa.</p>\n</div></span>\n\n \n <span id=\"purpose\"><b>Description <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Informative Content\" class=\"informative-flag\">I</a>:</b> <div><p>The PHR Account Holder must be confident that the system can reliably and uniquely identify them and provide access to their health record. Nothing precludes the PHR Account Holder from having more than one PHR such as a tethered PHR-S with their Primary Care Provider and a separate self-maintained PHR. The following functions apply to a single PHR system (PHR-S).</p>\n</div></span>\n \n\n \n <span id=\"actors\"><b>Actors:</b><br/> ehr</span>\n \n\n \n <span id=\"requirements\"><b>Criteria <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b></span>\n \n <table id=\"statements\" class=\"grid dict\">\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>PH.1.1#01</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD present a user guide or training material to assist the PHR Account Holder in installing, initializing, registering, or operating their PHR.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>PH.1.1#02</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to store more than one unique identifier for each PHR Account Holder's record. For example, the PHR Account Holder may have received health information from multiple caregivers, each caregiver having a unique Patient Identifier for that PHR Account Holder (also known as an Account Number). When the PHR Account Holder shares information with an individual caregiver, the PHR Account Holder may desire to utilize the Patient Identifier that is known to that specific caregiver.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>PH.1.1#03</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to capture, store, and integrate and/or link the PHR Account Holder's unique identifiers from multiple external sources (e.g., medical record number, insurance account number, or voluntary unique identifiers).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>PH.1.1#04</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to uniquely identify a PHR Account Holder.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>PH.1.1#05</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability (through a controlled method) to capture, integrate, and/or link information that is determined to be the PHR Account Holder's information that is stored in external systems. Note: A controlled method enables the PHR Account Holder to choose a course of action from a limited set of actions. For example, the PHR-S could provide a controlled method by which the PHR Account Holder could choose to link to an external DICOM image, but import the Report regarding that DICOM image instead.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>PH.1.1#06</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n <i>conditional</i>\n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>IF health information has been incorrectly associated with a PHR Account Holder, THEN the system SHALL provide the ability to annotate the information as being erroneous (or as believed to be erroneous) in the PHR Account Holder's account in which it was incorrectly associated, and represent that information as being erroneous.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>PH.1.1#07</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n <i>dependent</i>\n \n \n <i>conditional</i>\n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>IF health information has been incorrectly associated with a PHR Account Holder, THEN the system SHOULD provide the ability to transmit information regarding the error to the source of the information according to organizational policy and/or jurisdictional law.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>PH.1.1#08</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n <i>dependent</i>\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to archive, delete, and/or purge part or all of a PHR Account Holder's information (e.g., information that is obsolete, inactive, or nullified) according to user preference and/or consent, organizational policy (e.g., according to a statement of terms and conditions), and/or jurisdictional law.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n </table>\n</div>"
  },
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/structuredefinition-wg",
      "valueCode" : "ehr"
    }
  ],
  "url" : "http://hl7.org/ehrs/uv/phrsfmr2/Requirements/PHRSFMR2-PH.1.1",
  "version" : "2.0.1-ballot",
  "name" : "PH_1_1_Identify_and_Maintain_a_PHR_Account_Holder_Record",
  "title" : "PH.1.1 Identify and Maintain a PHR Account Holder Record (Function)",
  "status" : "active",
  "date" : "2025-04-03T15:15:30+00:00",
  "publisher" : "EHR WG",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://www.hl7.org/Special/committees/ehr"
        }
      ]
    }
  ],
  "description" : "Unambiguously identify the PHR Account Holder; correctly link the information with the PHR Account Holder and vice-versa.",
  "purpose" : "The PHR Account Holder must be confident that the system can reliably and uniquely identify them and provide access to their health record. Nothing precludes the PHR Account Holder from having more than one PHR such as a tethered PHR-S with their Primary Care Provider and a separate self-maintained PHR. The following functions apply to a single PHR system (PHR-S).",
  "statement" : [
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "PHRSFMR2-PH.1.1-01",
      "label" : "PH.1.1#01",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "The system SHOULD present a user guide or training material to assist the PHR Account Holder in installing, initializing, registering, or operating their PHR."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "PHRSFMR2-PH.1.1-02",
      "label" : "PH.1.1#02",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL provide the ability to store more than one unique identifier for each PHR Account Holder's record. For example, the PHR Account Holder may have received health information from multiple caregivers, each caregiver having a unique Patient Identifier for that PHR Account Holder (also known as an Account Number). When the PHR Account Holder shares information with an individual caregiver, the PHR Account Holder may desire to utilize the Patient Identifier that is known to that specific caregiver."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "PHRSFMR2-PH.1.1-03",
      "label" : "PH.1.1#03",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "The system SHOULD provide the ability to capture, store, and integrate and/or link the PHR Account Holder's unique identifiers from multiple external sources (e.g., medical record number, insurance account number, or voluntary unique identifiers)."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "PHRSFMR2-PH.1.1-04",
      "label" : "PH.1.1#04",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL provide the ability to uniquely identify a PHR Account Holder."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "PHRSFMR2-PH.1.1-05",
      "label" : "PH.1.1#05",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "The system SHOULD provide the ability (through a controlled method) to capture, integrate, and/or link information that is determined to be the PHR Account Holder's information that is stored in external systems. Note: A controlled method enables the PHR Account Holder to choose a course of action from a limited set of actions. For example, the PHR-S could provide a controlled method by which the PHR Account Holder could choose to link to an external DICOM image, but import the Report regarding that DICOM image instead."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "PHRSFMR2-PH.1.1-06",
      "label" : "PH.1.1#06",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : true,
      "requirement" : "IF health information has been incorrectly associated with a PHR Account Holder, THEN the system SHALL provide the ability to annotate the information as being erroneous (or as believed to be erroneous) in the PHR Account Holder's account in which it was incorrectly associated, and represent that information as being erroneous."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : true
        }
      ],
      "key" : "PHRSFMR2-PH.1.1-07",
      "label" : "PH.1.1#07",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : true,
      "requirement" : "IF health information has been incorrectly associated with a PHR Account Holder, THEN the system SHOULD provide the ability to transmit information regarding the error to the source of the information according to organizational policy and/or jurisdictional law."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/uv/phrsfmr2/StructureDefinition/requirements-dependent",
          "valueBoolean" : true
        }
      ],
      "key" : "PHRSFMR2-PH.1.1-08",
      "label" : "PH.1.1#08",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "The system SHOULD provide the ability to archive, delete, and/or purge part or all of a PHR Account Holder's information (e.g., information that is obsolete, inactive, or nullified) according to user preference and/or consent, organizational policy (e.g., according to a statement of terms and conditions), and/or jurisdictional law."
    }
  ]
}

XIG built as of ??metadata-date??. Found ??metadata-resources?? resources in ??metadata-packages?? packages.